In an open system, information is disclosed regarding the hardware configuration of a computer or the source code of the operating system (OS) of the computer. That enables a user to change the operating programs so as to create desired programs. Thus, in an open system, there is a possibility that the programs of the OS are changed for the purpose of attacking application programs. Such an attack by a third party is difficult to prevent simply by beefing up the OS for preventing the attack on application programs.
On the other hand, the hardware configuration is difficult to alter by a user. There are proposed secure processors that are configured to prevent an attack on programs, attempted by means of altering the OS. In such secure processors; the programs are encoded in a multitask environment along with the information used in those programs, so as to prevent the programs and the information from leaking to a third party or to prevent the programs from being altered. As a result, the process units generated in the programs can be executed in the correct sequence.
Meanwhile, there are many applications that are configured to include a plurality of modules running cooperatively. In a secure processor, there may be a situation in which each module only trusts a portion of another module. For example, each module is encoded and secured with a different key; each module runs in a different context; and each context is isolated from the OS or from other modules. The data exchanged among modules is not sent to potentially malcious OS or to the modules that are not running cooperatively. In this model, on the one hand, the private data within a particular module is protected by isolating the context thereof from other modules; while on the other hand, a shared area is used to communicate data that is required when modules run cooperatively.
As an application having such a module configuration, it is possible to think of a method of using shared libraries. In the case of using multiprocessing, since each process operates in an independent manner, it becomes necessary to have description about synchronizing the operations among the processes. Meanwhile, in an identical manner of creating a stand-alone application, it is sufficient to write the shared libraries according to the normal calling conventions. Moreover, since the operations are also performed in a sequential manner, there is an advantage that the description does not get difficult.
While using shared libraries in a secure processor, it is necessary to verify whether or not the modules attempting to run cooperatively are appropriate. There is a program for calling shared libraries that verifies the validness of shared libraries by performing authentication key exchange at the time of initializing the shared libraries. Then, at the time of calling a shared library, the program ensures that a particular entry point in that shared library is executed. Meanwhile, there is a technique in which verification of whether or not a caller module and a calling destination module are valid is performed using a key with which those modules are decoded.
Meanwhile, each module holds a context independently, and the execution control is managed by the OS. Hence, any module can start running due to the execution control of the OS. At that time, even a module that is waiting for being called from another module may start running. In this way, even if a particular module is waiting for being called from another module, that particular module starts running due to the execution control of the OS.
According to the techniques described above, although it is possible to verify the validness of a calling destination module, it cannot be determined whether or not the timing is right for the module that has been called to start running. Thus, when a plurality of modules run cooperatively, it becomes possible to change the execution sequence of those modules. That makes it difficult to ensure sequential running of modules in a fixed order such as in the case of shared libraries.
There is need to provide a program that can more reliably prevent changes from being made in the execution sequence by a third party.